The GPRS or Universal Mobile Telecommunications System (UMTS) is an evolution of the global system for mobile communications (GSM) standard to provide packet switched data services to GSM mobile stations. Packet-switched data services are used for transmitting chunks of data or for data transfers of an intermittent or bursty nature. Typical applications for 3rd Generation Partnership Project (3GPP) packet service include Internet browsing, wireless e-mail, video streaming, and credit card processing, etc. used by human users.
The main new network architecture entities in the 2G/3G network are GGSN and Serving GPRS Support Node (SGSN) and those in a 4G network are Serving Gateway S-GW and PDN Gateway P-GW. In brief, the SGSN/S-GW is a point of attachment for transport purposes of the data sessions from a radio access network while GGSN/P-GW acts as an Internet Protocol (IP) end point and a router to external networks. The GGSN/P-GW contains routing information for GPRS mobile devices, which is used to tunnel packets through the IP based internal network to the correct SGSN/S-GW. When a mobile device wishes to get access to data services such as the Internet, it must first attach to the mobile network and then obtain an IP address from GGSN/P-GW. This is known as activating a Packet Data Protocol (PDP)-Context in 2G/3G and as activating a bearer in 4G.
Typically, a Transmission Control Program (TCP) session is first established between a user equipment (UE) and a server beyond the mobile network gateways GGSN/P-GW to allow a Hypertext Transfer Protocol (HTTP) session, or a session using any other appropriate upper layer protocol, between the UE and server. The GGSN/P-GW acts as a transparent gateway between the mobile network and the Internet network. This allows the UE to make an HTTP request to the server to access, for example, an Internet address. Note that while the rest of the disclosure refers to GGSN, to the skilled in the art it would be clear that it applies to P-GW as well.
The TCP behavior through a transparent proxy and content enrichment related issues are described in prior art U.S. Patent Publication 20130024523A1 which is hereby incorporated by reference. Some of the text and figures of this reference are reproduced in the disclosure for reference and for providing a context. In general, TCP provides reliable, ordered delivery of a stream of bytes from one application to another. TCP uses a sequence number to identify each segment of data. The sequence number identifies the order of the segments sent from each computer so that the data can be reconstructed in order, regardless of any fragmentation, disordering, or packet loss that may occur during transmission. TCP also uses a cumulative acknowledgment scheme, where the receiver sends an acknowledgment number which signifies that the receiver has received all data preceding the acknowledged sequence number. A TCP message consists of a header and a body section. The TCP header includes identifiers (such as source IP address, destination IP address, source port, destination port, protocol), the sequence and acknowledgement numbers, and other TCP header fields. The body section follows the header and contains the payload data carried for the application. The TCP body section may also contain a header for an application layer protocol. TCP packets are validated by a checksum. The checksum is included in each packet for the receiver to verify the integrity of the transmission.
Referring now to Prior Art FIG. 1, a UE 102 sends a Hypertext Transfer Protocol (HTTP) request message 110. The TCP sequence number (SEQ) is set to 85 and the TCP acknowledge number (ACK) is set to 1. The GGSN 104 receives the HTTP Request 110 and transparently forwards it to the server 106. The server 106 processes the HTTP Request 110 and based on that, a new TCP sequence number is required to be calculated for the response. The TCP SEQ is set to 1000 and the TCP ACK is set to 85, to acknowledge that the server has received all data up to sequence number 85. The server 106 sends HTTP Response 114 to the GGSN 104, which is forwarded to the UE 102.
HTTP header enrichment (HE) enables the GGSN to insert HTTP headers into a HTTP request in real time. HTTP header enrichment may be triggered by a packet inspection rule, indicating that information must be added to the header of the HTTP request. The enriched content in the HTTP header will be used by other servers in the network to complete specific authorization, accounting, etc. When HTTP header enrichment is employed, the GGSN is no longer able to act fully transparent. When HTTP headers are added to an HTTP request, the packet size will be changed by the addition of the new content to the message. In order to handle the new packet size, the GGSN must adjust the TCP sequence and acknowledgement numbers.
Referring now to Prior Art FIG. 2, the UE 102 tries to access http://address.com and sends an HTTP Request 120. The TCP SEQ number is set to 85 and the TCP ACK number is set to 1. The GGSN 104 receives the message and inserts HTTP headers into the HTTP Request 120. A new TCP SEQ number is calculated to be 131 based on the new enriched header and content length. HTTP Request 122, including the added HTTP headers and adjusted TCP SEQ number is sent to the server 106. The server 106 processes the HTTP Request 122 and based on the result, a new TCP SEQ number is calculated. The TCP SEQ is set to 1000 and the TCP ACK is set to 131. HTTP Response 124 is sent from the server 106 to the GGSN 104 and includes the content of http://address.com in its body. Before the HTTP Response can be forwarded to the UE 102, the TCP ACK number must be changed to match the original TCP SEQ number. The GGSN 104 must also recalculate the TCP and IP checksum in order to ensure packet validity at both the sender and the receiver sides.
The GGSN 104 must store this information related to the enriched HTTP session so that it is able to properly adjust the TCP sequence and acknowledgement numbers so as to not break the TCP communication session between the UE 102 and the server 106. The GGSN 104 will store a table or database of this enriched flow information for all active flows. The table may include session identifiers (i.e. source IP address, destination IP address, source port number), destination adjustments made to the TCP sequence and/or acknowledgement numbers between the messages sent to the UE 102 and the server 106. Returning to FIG. 2, the GGSN 104 modifies the TCP ACK number of HTTP Response 124, in accordance with the flow information it has previous stored, to match the original TCP SEQ number. As such, the TCP SEQ is set to 1000 and the TCP ACK is changed to 85 from 131. HTTP Response 126 is sent to the UE 102 with these adjustments, and the UE 102 receives the response 126 with an expected ACK value of 85. Storage of this flow information requires considerable memory and resources on the GGSN. The GGSN is required to keep this information about all the enriched flows while they are active and running traffic. However once these flows are idle for a configured predetermined amount of time the GGSN can release the occupied memory resources for these idle flows to be used in other operations. The idle time the GGSN waits before deleting the flow information and releasing the resources is called the flow timeout memory and resources on the GGSN.
Presently, terminating the flows in the GGSN only involves releasing resources in the GGSN. The possibility exists that further TCP messages related to a deleted flow may still originate from a UE or from a web server. When this scenario occurs, the GGSN no longer has the flow information stored to make the required adjustments to the TCP sequence or acknowledge numbers before forwarding the message. This mismatch in the TCP sequence and acknowledgement numbers causes TCP miscommunication between the client and server which can lead to a TCP signaling storm in the network, causing high central processing unit (CPU) utilization in the GGSN and a waste of network resources.
FIG. 3 illustrates an example of a TCP signaling storm scenario. HTTP Request 300 is enriched at GGSN 104 and the modified HTTP Request 302 is forwarded to the server 106, in the same manner as FIG. 2. Likewise, HTTP Response 304 is adjusted accordingly at the GGSN 104 and forwarded to the UE 102 as HTTP response 306. At step 308, the flow timeout expires and the flow information and resources are released at the GGSN 104. Sometime after the expiration 308, the server 106 attempts to send a TCP FIN message 310, for example, to the UE 102 to teardown the TCP session. Since the flow information has been deleted at the GGSN 104, the GGSN will not make the necessary adjustments to the TCP sequence and acknowledgement of the content enrichment procedure. The GGSN 104 will now act transparently and forward TCP FIN 312 to the UE 102 with the same TCP sequence and acknowledgement numbers received from the server 106. The UE 102 does not expect to receive this message. According to its TCP session identifier, the UE 102 expects the TCP acknowledgement number to be 85 not 131. It will then send a TCP ACK message 314 to indicate to the server 106 the expected TCP sequence and acknowledgement numbers, SEQ=85, ACK=1000. The GGSN 104 again simply forwards this message to the server 106, without adjusting the TCP sequence or acknowledgement numbers, as TCP ACK 316. The server 106, in turn, does not expect to receive this message according to the TCP standards and it will send another TCP FIN message 318 to indicate to the UE 102 that it is expecting to receive a TCP ACK number of 131. One skilled in the art will appreciate that message 318 can be a TCP ACK, TCP FIN or TCP FIN-ACK message, however, TCP FIN will be used for exemplary purposes in this scenario. TCP FIN 318 is handled by the GGSN 104 and UE 102 as described above for TCP FIN 312 and forwarded as TCP FIN 320. This causes a TCP signaling storm between the UE 102 and the server 106 which may be extremely harmful for the CPU utilization of the GGSN 104 due to the high volume and high rate of messages it needs to process and forward.
After describing the problem associated with content enrichment reference US 20130024523A1 goes on to present an invention that avoids signaling storm scenario by sending RESETs to each end whenever flows are to be deleted from GGSN memory as illustrated in FIG. 4.